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Abstract 
This document introduces extensions to Mobile IPv6 that allow nodes 
to bind one or more flows to a care-of address. These extensions 
allow multihomed nodes to instruct home agents and other Mobile IPv6 
entities to direct inbound flows to specific addresses. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6089. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
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1. Introduction 


Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and 
Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node / 
mobile router to manage its mobility using the binding update 
message, which binds one care-of address to one home address and 
associated mobile networks. The binding update message can be sent 
to the home agent. In Mobile IPv6, the binding update can also be 
sent to a correspondent node or to a mobility anchor point (see 
[RFC5380]). The semantics of the binding update are limited to 
care-of address changes. That is, [RFC3775], [RFC5555], and 
[RFC3963] do not allow a mobile node / mobile router to bind more 
than one address to the home address. In [RFC5648], Mobile IPv6 and 
NEMO Basic Support are extended to allow the binding of more than one 
care-of address to a home address. This specification further 
extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to 
Specify policies associated with each binding. A policy can contain 
a request for special treatment of a particular IPv4 or IPv6 flow, 
which is viewed as a group of packets matching a traffic selector. 
Hence, this specification allows a mobile node / mobile router to 
bind a particular flow to a care-of address without affecting other 
flows using the same home address. In addition, this specification 
allows to bind a particular flow to a particular care-of address 
directly with correspondent node and mobility agents (i.e., home 
agents [RFC3775] and mobility anchor points [RFC5380]). 


In this document, a flow is defined as a set of IP packets matching a 
traffic selector. A traffic selector can identify the source and 
destination IP addresses, transport protocol number, the source and 
destination port numbers and other fields in IP and higher-layer 
headers. This specification does not define traffic selectors, which 
are going to be defined in other specifications. This specification, 
however, does define the traffic selector sub-option format to be 
used for any specific traffic selector. 


Using the flow identifier option introduced in this specification, a 
mobile node / mobile router can bind one or more flows to a care-of 
address while maintaining the reception of other flows on another 
care-of address. The mobile node / mobile router assembles the flow 
binding requests based on local policies, link characteristics, and 
the types of applications running at the time. Such policies are 
outside the scope of this document. 


It should be noted that the flow identification mobility option can 
be associated with any binding update, whether it is sent to a 
mobility agent or a correspondent node. 
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Note that per-packet load balancing may have negative impacts on TCP 
congestion avoidance mechanisms as it is desirable to maintain order 
between packets belonging to the same TCP connection. This behavior 
is specified in [RFC2702]. Other negative impacts are also foreseen 
for other types of real-time connections due to the potential 
variations in round-trip time between packets. Moreover, per-packet 
load-balancing will negatively affect traffic with anti-replay 
protection mechanisms. Hence, per-packet load balancing is not 
envisioned in this specification. 


In the rest of the document, the term "mobile node" is used to 
designate either a mobile node as defined in [RFC3775] and [RFC5648], 
or a mobile router as defined in [RFC3963] unless stated otherwise. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Terminology 


Terms used in this document are defined in [RFC3753] and [RFC4885]. 
The following terms are also used in this document: 


Flow: A flow is a sequence of packets for which the mobile node 
(MN) desires special handling either by the home agent (HA), the 
corresponding node (CN) or the mobility anchor point (MAP). 


Traffic Selector: One or more parameters that can be matched 
against fields in the packet's headers for the purpose of 
classifying a packet. Examples of such parameters include the 
Source and destination IP addresses, transport protocol number, 
the source and destination port numbers, and other fields in IP 
and higher-layer headers. 


Flow binding: It consists of a traffic selector, and one or more 
binding identifiers (BIDs). IP packets from one or more flows 

that match the traffic selector associated with the flow binding 
are forwarded to the BIDs associated with the same flow binding. 


Flow Identifier: A flow identifier uniquely identifies a flow 
binding associated with a mobile node. It is generated by a 
mobile node and is cached in the table of flow binding entries 
maintained by the MN, HA, CN, or MAP. 
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4. Mobile IPv6 Extensions 


This section introduces extensions to Mobile IPv6 that are necessary 
for supporting the flow binding mechanism described in this document. 


4.1. Definition Update for Binding Identifier Mobility Option 


This specification updates the definition of the Binding Identifier 
Mobility option defined in [RFC5648], as follows: 


1 2 3 
O: 12° °3' 4° oO" FB. 9.0.1.2.3 4 5 6 892-0 1.2 34 5 9-T 8 9.0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type = 35 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Binding ID (BID) | Status |a| | BID-PRI | 
+-t—4+-4F-4+-4-4-4-4-4-4-4-4-4-4-4-4------- a i 
+ + 
IPv4 or IPv6 Care-of Address (CoA) 

+ + 
4--------------------------------------------------------------- + 


Figure 1: The Binding Identifier Mobility Option 
BID-PRI 


This is a 7-bit unsigned integer placing each BID to a relative 
priority (PRI) with other registered BIDs. Value ’0’ is 
reserved and MUST NOT be used. A lower number in this field 
indicates a higher priority, while BIDs with the same BID-PRI 
value have equal priority meaning that, the BID used is an 
implementation issue. This is consistent with current practice 
in packet classifiers. 


4.2. Flow Identification Mobility Option 


The flow identification mobility option is a new mobility option 
[RFC3775], and it is included in the binding update and 
acknowledgement messages. This option contains information that 
allows the receiver of a binding update to install policies on a 
traffic flow and route it to a given care-of address. Multiple 
options may exist within the same binding update message. The 
alignment requirement for this option is 2n. 
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0 1 2 3 
0'.1:.2([-:3::4..:.5::6. 7 8) 98 01. 2" 3-4- 576, 7 8. 9:0 1 2 34.306 TB: 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Option Type | Option Len | FID 
V—R—R—R-R-------R-R-———---.-—.-.-.———---.-— L4 
| FID-PRI | | Reserved | Status 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sub-options (optional) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 2: The Flow Identification Mobility Option 
Option Type 
45 
Option Len 
Length of the option in octets as per [RFC3775]. 


FID 


The Flow Identifier field is a 16-bit unsigned integer that 
includes the unique identifier for the flow binding. This 
field is used to refer to an existing flow binding or to create 
a new flow binding. The value of this field is set by the 
mobile node. FID = 0 is reserved and MUST NOT be used. 


FID-PRI 


This is a 16-bit unsigned integer priority field to indicate 
the priority of a particular option. This field is needed in 
cases where two different flow descriptions in two different 
options overlap. The priority field decides which policy 
should be executed in those cases. A lower number in this 
field indicates a higher priority. Value ’0’ is reserved and 
MUST NOT be used. FID-PRI MUST be unique to each of the flows 
pertaining to a given MN. In other words, two FIDs MUST NOT be 
associated with the same FID-PRI value. 


Status 


This 8-bit unsigned integer field indicates the success or 
failure of the flow binding operation for the particular flow 
in the option. This field is not relevant to the binding 
update message as a whole or to other flow identification 
options. This field is only relevant when included in the 
Binding Acknowledgement message and must be ignored in the 
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binding update message. The following values are reserved for 
the Status field within the flow identification mobility 
option: 

O0 Flow binding successful 

128 Administratively prohibited 

129 Flow binding rejected, reason unspecified 

130 Flow identification mobility option malformed 

131 BID not found 


132 FID not found 


133 Traffic selector format not supported 


Sub-options (optional) 


Zero or more sub-options, defined in Section 4.2.1. 


4.2.1. Flow Identification Sub-Options Definition 


Flow identification sub-options are encoded within the remaining 


Space 


of the flow identification mobility option, using a sub-option 


type-length-value (TLV) format as follows: 


0 
0 


1 2 3 
1.2 3450729899 012 3.4 5.07 8 9 0 12 3 45 6 7.8 9 0. 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sub-Opt Type | Sub-Opt Length | Sub-Option Data... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: Flow Identification Sub-Option Format 


Sub-Opt Type 


Tsirtsis, 


8-bit unsigned integer indicating the sub-option Type. When 
processing a flow identification mobility option containing an 
option for which the sub-option Type value is not recognized by 
the receiver, the receiver MUST silently ignore and skip over 
the sub-option, correctly handling any remaining sub-options in 
the same option. 
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Sub-Opt Len 


8-bit unsigned integer, representing the length in octets of 
the flow identification sub-option. This field indicates the 
length of the sub-option not including the Sub-Opt Type and 
Sub-Opt Length fields. Note that Sub-Opt Type ’0’ 

(Section 4.2.1.1) is a special case that does not take a Sub- 
Opt Length field. 


Sub-Option Data 


A variable length field that contains data specific to the sub- 
option. 


The following subsections specify the sub-option Types that are 
currently defined for use in the flow identification option. 
Implementations MUST silently ignore any sub-options that they do not 
understand. 


These sub-options may have alignment requirements. Following the 
convention in [RFC3775], regarding mobility options, these sub- 
options are aligned in a packet so that multi-octet values within the 
sub-option Data field of each sub-option fall on natural boundaries 
(i.e., fields of width n octets are placed at an integer multiple of 
n octets from the start of the header, for n = 1, 2, 4, or 8). 


4.2.1.1. Padl 


The Padl sub-option does not have any alignment requirements. Its 
format is as follows: 


0 
01234567 
———— 
| Sub-Opt Type | 
+-+-+-+-+-+-+-+-+ 


Sub-Opt Type 
0 


NOTE: The format of the Padl sub-option is a special case -- it has 
neither sub-option Length nor sub-option Data fields. 


The Padl sub-option is used to insert one octet of padding in the 
flow identification option. If more than one octet of padding is 
required, the PadN sub-option, described next, should be used rather 
than multiple Padl sub-options. 
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4.2.1.2. PadN 


The PadN sub-option does not have any alignment requirements. Its 
format is as follows: 


0 1 

0-.1-2-.3 4 502 4.8. 9.0. 1.2-3 4.5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- —-—------- 
| Sub-Opt Type | Sub-Opt Len | Option Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 


Sub-Opt Type 

T 
Sub-Opt Len 

Set to the length of the sub-option. 
Sub-Opt Data 


O0 or more bytes set to 0 by the sender and ignored by the 
receiver. 


The PadN sub-option is used to insert two or more octets of padding 
in the flow identification mobility option. For N octets of padding, 
the sub-option Length field contains the value N, and the sub-option 
Data field consists of N-2 zero-valued octets.  PadN sub-option Data 
MUST be ignored by the receiver. 


4.2.1.3. Binding Reference Sub-Option 


This section introduces the binding reference sub-option, included in 
the flow identification mobility option. A node MUST NOT include 
more than one binding reference sub-options in a given flow binding 
identification option. The binding reference sub-option includes one 
or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648]. 
This sub-option associates the flow described in a flow 
identification mobility option with one or more registered BIDs. 


When binding a flow using this sub-option, the binding identifier 
mobility option, defined in [RFC5648], MUST be included in either the 


same or an earlier binding update (BU). The binding reference sub- 
option is shown below. The alignment requirement for this sub-option 
is 2n. 
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0 1 2 3 
OM D2 384 15. 6 F289 Ok, 23 4e $76, 7.8: 90 A 2; 3-4. 5:6. 7-8. 90. X 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|Sub-Opt Type | Sub-Opt Len | BID 
€——REE0—————^————————————Á — Á 
| BID 


+-+-+-+-+-+-+-+-+-+- 
Figure 4: The Binding Reference Sub-Option 
Sub-Opt Type 
2 
Sub-Opt Len 
Variable 


BID 


A 16-bit unsigned integer indicating the BID that the mobile 
node wants to associate with the flow identification option. 
One or more BID fields can be included in this sub-option. 

Since each BID is 2 bytes long, the value of the Sub-opt Len 


field indicates the number of BIDs present. Number of BIDs = 
Sub-Opt Len/2. 


4.2.1.4. Traffic Selector Sub-Option 


The traffic selector sub-option includes the parameters used to match 
packets for a specific flow binding. A node MUST NOT include more 


than one traffic selector sub-option in a given flow binding 
identification option. 


0 1 2 3 
0.1 2 3.4.56 7.8 9.0 12 3 4 5-6 7.8.9 0.1.2 3.4 5 6 7:8 9-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sub-Opt Type | Sub-Opt Len | TS Format | Reserved | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Traffic Selector 
+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: The Traffic Selector Sub-Option 
Sub-Opt Type 


3 
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Sub-Opt Len 
Variable 
TS Format 


An 8-bit unsigned integer indicating the Traffic Selector Format. 
Value "0" is reserved and MUST NOT be used. 


Reserved 


An 8-bit reserved field. It MUST be set to zero by the sender and 
ignored by the receiver. 


Traffic Selector 


A variable-length field, the format and content of which is out of 
Scope for this specification. The traffic selector defined in 
[RFC6088] is mandatory to implement. 


4.2.2. Flow Summary Mobility Option 


The flow summary mobility option is a new mobility option [RFC3775], 
which includes one or more flow identifiers (FIDs) for the purpose of 


refreshing their state. The alignment requirement for this option is 
2I 


0 1 2 3 
0. 1- 2-:3::44-5.:6. 7.08. 950. b:2-3.4—5- 6 17 8.9.0 1:23 4 5.6 7-8 9 0l 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| Option Type | Option Len | FID 
íÓ——R—————A——————————————— ——À 
| BID. dudes 


+-+-+-+-+-+-+-+-+-+- 
Figure 6: The Flow Summary Mobility Option 
Option Type 
44 
Option Length 


Length of the option in octets as per [RFC3775]. 
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FID 


A 16-bit unsigned integer indicating a registered FID. One or 
more FID fields can be included in this option. Number of FIDs 
= Option Len/2. 


4.3. Flow Bindings Entries List and Its Relationship to Binding Cache 


The conceptual Mobile IPv6 binding cache was defined in [RFC3775] to 
identify the mobile IP state maintained by the mobile node, mobility 
agent, and correspondent node. The binding cache includes, among 
others, the mobile node’s home address, the registered care-of 
address, and the lifetime of the binding. The binding cache has been 
extended by [RFC5648] to include more than one care-of addresses and 
to associate each of them with a binding identifier (BID). 


This specification does not modify the Mobile IPv6 binding cache any 
further. 


Flow bindings can be thought of as a conceptual list of entries that 
is separate from the binding cache. The flow bindings list contains 
an entry for each of the registered flow bindings. Flow binding 
entries point to an entry in the binding cache by means of the BID. 
Each flow binding entry includes the following parameters: 


o FID (Flow Identifier): For a given mobile node, identified by its 
primary home address, the FID MUST uniquely identify an entry, 
i.e., a unique flow binding. Each mobile node can only have a 
single entry identified by a given FID at any one time. A given 
FID number space is used for all the addresses associated to a 
given MN by the HA (e.g., via [RFC3963]). Different mobile nodes 
use the same FID number space. 


o A Traffic Selector: Included in a traffic selector sub-option. 


o BID(s): The list of BIDs associated with the entry as defined by 
the binding reference sub-option included in the FID option that 
created it. 


o Active/Inactive flag: This flag indicates whether the entry is 
active or inactive. 


o FID-PRI: This field indicates the priority of the flow binding and 
is used to break the tie between overlapping flow bindings. 
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The flow bindings list is associated with a given mobile node, and 
the correspondent binding cache. An entry in the flow bindings list, 
however, is identified by the FID and the list is ordered according 
to the FID-PRI field as defined in the FID option that created each 
entry. 


A valid BID is required to make the entry ‘Active’. If all of the 
BIDs pointed to by a given entry are deregistered [RFC5648], the flow 
binding entry becomes 'Inactive', in other words it does not affect 
data traffic. Note that an entry becomes 'Inactive' only if all of 
the BIDs are deregistered. If only some of the BIDs are still valid, 
the invalid BIDs are simply ignored. 


Also, note that the state described in this section is maintained by 
the mobile node as well as in mobility agents and correspondent 
nodes. As such, the mobile node is fully aware of which BIDs are 
valid at any time and which flow binding entries are active/inactive. 
Section 5 defines how these flow binding entries are manipulated by 
the mobile node in detail. 


As an example, the following represents an ordered flow binding entry 
table for a mobile node that has registered multiple care-of 
addresses and flow bindings. 


FID-PRI FID Traffic Selector BIDs A/I 
10 4 TCP 2 Active 
30 2 srcAddr-IPy 4 Inactive 
40 5 UDP 17:3 Active 


Ordered Flow Binding Entries 


According to the above list of flow binding entries, all TCP traffic 
will match the first entry, and will be forwarded to BID2, 
corresponding to a given care-of address (IP3), as shown below. 


The second entry is marked as 'Inactive' since the BID 4 does not 
exist in the ordered list of BID entries below. Inactive entries do 
not affect traffic, i.e., packets are not matched against them. 


Any UDP traffic that does not match any of the earlier entries will 
match the third rule, at which point it will be replicated and 
forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and 
IP2 shown below. 
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94 


Da 


Finally, any remaining packets that do not match any of the entries 
above will be simply forwarded to the care-of address indicated by 
the highest order BID in the table below. In the example, such 
packets will be forwarded to BID1 corresponding to care-of address 
IP1. 


BID-PRI BID CoA 
20 1 IP1 
30 3 IP2 
30 2 IP3 


Ordered BID Entries 


Mobility agent and corresponding node implementations should take 
care to avoid flow binding rules affecting the fundamental operation 
of Mobile IPv6 and its extensions. In particular, flow binding rules 
MUST NOT apply to Mobile IPv6 signaling generated by mobility agents 
and corresponding nodes communicating with a given mobile node, since 
that could adversely affect the operation of the protocol. Other, 
non-MIPv6 traffic generated by these entities SHOULD be matched 
against the mobile node’s flow binding rules as normal. 


Protocol Operations 
1. General 


This specification introduces a flow bindings list of entries and an 
ordered list of flow binding identifiers, allowing mobile nodes to 
associate flow binding policies with the registered care-of 
addresses. 


The flow identification mobility option defines how the mobile node 
can control a set of flow binding entries maintained in a mobility 
agent, or correspondent node. 


This specification allows mobile nodes to direct flows to a 
particular care-of address. The granularity of what constitutes a 
flow depends on the traffic selector used. 


The remainder of this section discusses how mobile nodes can use the 
options and sub-options defined in this document when sending binding 
updates to the correspondent node, home agent, or mobility anchor 
point. In addition, refresh, deletion, and modification of flow 
binding entries are all discussed below. 
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5.1.1. Preferred Care-of Address 


Any node that supports this specification MUST maintain an ordered 
list of care-of addresses for each mobile node for which it maintains 
a list of flow bindings. The ordered list of care-of addresses is 
built based on the BID-PRI field of the binding identifier mobility 
option (see Section 4.1). 


The ordered list of BIDs is used to determine how to forward a packet 
to a given mobile node when the packet does not match any of the flow 
binding entries defined in Section 4.3. A packet that does not match 
any of the flow binding entries SHOULD be forwarded to the care-of 
address identified by the BID with the highest priority, i.e., lowest 
BID-PRI value. 


5.2. Mobile Node Considerations 


This specification allows the mobile node to maintain several 
bindings with its mobility agent and correspondent nodes, and it 
allows it to direct packets to different care-of addresses according 
to flow bindings. 


The mobility agent and correspondent node list of flow bindings is 
manipulated by the mobile node, via flow identification and flow 
summary mobility options included in binding update messages. Each 
flow binding update can add, modify, refresh, or delete a given 
binding. More than one flow identification mobility option MAY be 
included in the same binding update, but each of them MUST include a 
different FID. In other words, two flow identification options in 
the same message cannot be about the same flow binding. 


All flow binding state MUST be refreshed in every binding update the 
mobile node sends. Any previously registered flow binding that is 
not included in a given binding update will be deleted. So, any flow 
bindings that are not added or modified by a flow identification 
mobility option, but have previously registered and need to be 
maintained, MUST be included in a flow summary mobility option. 


5.2.1. Sending BU with BID Options 


This specification (see Section 4.1) updates the definition of the 
binding identifier mobility option, originally defined in [RFC5648]. 
According to this specification, the BID option includes a BID-PRI 
field assigning each registered care-of address a priority, and thus 
places them in an ordered list, as also described in Section 4.3. 


To ensure backwards compatibility with [RFC5648], for the purpose of 
this specification, the field BID-PRI MUST NOT be set to zero. 
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Receiver implementation of this specification will take a BID-PRI 
field of value zero as an indication that this is a BID option of the 
format defined in [RFC5648]. 


Mobile nodes supporting this specification MUST use the BID option 
format defined in Section 4.1. Mobile nodes MUST also register all 
care-of addresses using the updated BID option format, either in the 
same BU as any flow identification mobility options using them or in 
earlier BUs. 


5.2.2. Sending BU with Flow Identification Mobility Options 
5.2.2.1. New Flow Bindings 


When adding a new flow binding, a mobile node sends the flow 
identification mobility option in the binding update, with the FID 
field set to a value that is not already present in the list of flow 
binding entries maintained by the receiver. The care-of address(es) 
associated with each flow identification mobility option in the 
binding update must be logically registered by this binding update, 
or must have already been registered by the receiver of the binding 
update in an earlier binding update, as defined in Section 5.2.1. 


The flow identification mobility option MUST include a unique flow 
identifier in the FID field. The FID need only be unique for the 
receiver of the binding update and for the same sender, i.e., the 
same FID can be used across different receivers of the binding 
update, for the same sender. The FID-PRI field is set to the desired 
unique priority of the FID, defining the order of the flow binding to 
be added in the list of flow binding entries, as defined in 

Section 4.3. The Status field is set to zero in all binding update 
messages. 


Since this flow identification mobility option is requesting the 
addition of a new flow binding in the list of flow bindings 
maintained by the receiver, the mobile node MUST include exactly one 
traffic selector sub-option (see Section 4.2.1.4) describing the flow 
associated with the new flow binding. The TS Format field of the 
traffic selector sub-option MUST be set to the non-zero value of the 
format used by the mobile node. 


The mobile node MUST also include exactly one BID reference sub- 
option (see Section 4.2.1.3) to associate the flow binding with a 
given set of BIDs and corresponding CoAs. 
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5.2.2.2. Updating Flow Bindings 


5 


S24 


Flow binding modification is essentially a process where parameters 
associated with an existing flow binding in the list of flow binding 
entries are replaced by parameters included in the flow 
identification mobility option, and the same FID is maintained. With 
this procedure, the mobile node can change the priority, the BID(s), 
and/or the traffic selector associated with a flow binding. 


To modify an existing flow binding, the mobile node MUST send a 
binding update with a flow identification option, with the FID field 
set to one of the FID values already in the list of flow binding 
entries. The FID-PRI field MUST be set to the priority value for the 
flow binding entry. The Status field is set to zero since this 
option is in a binding update. 


The mobile node MAY include exactly one traffic selector sub-option 
(see Section 4.2.1.4) describing the updated flow to be associated 
with the flow binding. The mobile node MAY, however, omit the 
traffic selector sub-option if it wants the traffic selector 
currently associated with the flow binding entry identified by the 
FID field to be maintained. 


The mobile node MAY include exactly one binding reference sub-option 
(see Section 4.2.1.3) to associate the existing flow binding with a 
new set of CoAs. The mobile node MAY omit the binding reference sub- 
option if it wants the BIDs currently associated with the flow 
binding entry identified by the FID field to be maintained. 


Note that it is also possible for the mobile node to effectively 
modify the effect of a flow binding entry without actually changing 
the entry itself. This can be done by changing the CoA associated 
with a given BID, which is a process defined in detail in [RFC5648]. 


3. Sending BU with a Flow Summary Option 


When the mobile node sends a binding update, it MUST refresh all flow 
bindings it wants to maintain even if it does not want to change any 
of their parameters. 


To refresh an existing flow binding, the mobile node MUST send a 
binding update with a flow summary option. The flow summary option 
MUST include one or more FID fields, as indicated in Section 4.2.2. 
Each FID field included MUST be set to one of the FID values already 
in the list of flow binding entries. Each flow summary mobility 
option can identify up to 127 FIDs, so more than one such option can 
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be included in a binding update message as required. A given FID 
SHOULD NOT be included more than once in all of the flow summary 
mobility options included in a given binding update message. 


Any flow bindings (active or inactive) that are not identified ina 
binding update will be removed from the list of flow binding entries. 


Note that any inactive flow bindings, i.e., flow bindings without 
associated BIDs that are marked as 'Inactive' in the list of flow 
binding entries (see Section 4.3), MUST also be refreshed, or 
modified, to be maintained. If they are not included in a BU 
message, they will be removed. 


5.2.4. Removing Flow Bindings 


Removal of flow binding entries is performed implicitly by omission 
of a given FID from a binding update. 


To remove a flow binding, the MN simply sends a binding update 
message that includes flow identification and flow summary mobility 
options for all the FIDs that need to be refreshed, modified, or 
added, and simply omits any FIDs that need to be removed. 


Note that a mobile node can also render a flow binding inactive by 
removing the BIDs associated with it, without removing the flow 
binding itself. The procedure for removing a BID is defined in 
detail in [RFC5648]. 


When all the BIDs associated with a flow binding are removed, the 
flow binding MUST be marked as 'Inactive' in the list of flow binding 


entries, as shown in Section 4.3. In other words, the state 
associated with the flow binding MUST be maintained, but it no longer 
affects the mobile node's traffic. The MN can return an inactive 


flow binding to the active state by using the flow binding 
modification process, described in Section 5.2.2.2, to associate it 
again with one or more valid BIDs. 


5.2.5. Returning Home 


This specification is compatible with the home registration 
procedures defined in [RFC3775] and [RFC5648]. More specifically, if 
the mobile node performs a deregistration in the [RFC3775] style, all 
of its bindings, including flow bindings are deleted. If the mobile 
node, however, performs a home registration in the [RFC5648] style, 
then the home link is associated with a specific BID and so, as far 
as this specification is concerned, it is treated as any other link 
associated with a given BID. 
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5.2.6. Receiving Binding Acknowledgements 


According to [RFC3775], all nodes are required to silently ignore 
mobility options not understood while processing binding updates. As 
such, a mobile node receiving a Binding Acknowledgement message in 
response to the transmission of a binding update message MUST 
determine if the Binding Acknowledgement message contains a copy of 
every flow identification mobility options included in the binding 
update. A Binding Acknowledgement without flow identification 
option(s), in response to a binding update with flow identification 
mobility option, would indicate the inability (or unwillingness) on 
behalf of the source node to support the extensions presented in this 
document. 


If a received Binding Acknowledgement contains a copy of each flow 
identification mobility option that was sent within the binding 
update, the Status field of each flow identification option indicates 
the status of the flow binding on the distant node. 


5.2.7. Return Routability Procedure 


A mobile node may perform route optimization with correspondent 
nodes, as defined in [RFC3775]. Route optimization allows a mobile 
node to bind a care-of address to a home address in order to allow 
the correspondent node to direct the traffic to the current location 
of the mobile node. Before sending a binding update to correspondent 
node, the Return Routability Procedure needs to be performed between 
the mobile node and the correspondent node. This procedure is not 
affected by the extensions defined in this document. 


5.3. HA, MAP, and CN Considerations 


This specification allows the mobility agents (home agents and 
mobility anchor points), and correspondent nodes to maintain several 
flow bindings for a given home address and to direct packets to 
different care-of addresses according to flow bindings. This section 
details the home agent operations necessary to implement this 
specification. These operations are identical for MAPs and CNs, 
unless otherwise stated. 


Note that route optimization is only defined for mobile nodes (MIPv6 
[RFC3775]) and not mobile routers (NEMOv6 [RFC3963]). Thus, these 
sections only apply to correspondent nodes with respect to mobile 
nodes and not mobile routers. 
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5.3.1. Handling Binding Identifier Mobility Options 


This specification (see Section 4.1) updates the definition of the 
binding identifier mobility option, originally defined in [RFC5648]. 
According to this specification, the BID option includes a BID-PRI 
field assigning each registered care-of address a priority, and thus 
places them in an ordered list (see Section 4.3). 


Home agents receiving BUs including BID options and flow 
identification options MUST logically process BID options first. 
This is because BID reference sub-options included in the flow 
identification mobility options might refer to BIDs defined in BID 
options included in the same message. 


The BID option is processed as defined in [RFC5648], but then the BID 
to care-of address mapping is placed in an ordered list according to 
the BID-PRI field of the BID option. 


Binding identifier registrations and deregistrations indirectly 
affect the MN’s flow binding entries. The home agent MUST update the 
flow binding entries table accordingly as BIDs are added or removed 
(as per [RFC5648]). For example, as discussed in Section 4.3, if all 
of the BIDs associated with a given flow binding entry are removed 
(i.e., become invalid) the entry MUST be marked as 'Inactive'. While 
if any of the invalid BIDs associated with an inactive flow binding 
entry are registered (i.e., become valid), the entry MUST be marked 
as 'Active'. 


5.3.2. Handling Flow Identification Mobility Options 


When the home agent receives a binding update that includes at least 
one flow identification mobility option, it first performs the 
operation described in section 10.3.1 of RFC 3775, followed by the 
operations defined in Section 5.3.1 of this document. 


Home agents that do not support this specification will ignore the 
flow identification mobility options and all their sub-options, 
having no effect on the operation of the rest of the protocol. 


If the binding update is accepted, and the home agent is willing to 
support flow bindings for this MN, the home agent checks the flow 
identification mobility options. 


If more than one flow identification mobility option in the same BU 


has the same value in the FID field, all the flow identification 
mobility options MUST be rejected. 
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If all FID fields have different values the flow identification 
mobility options can be processed further and in any order, as 
defined by the following subsections. 


5.3.2.1. Handling New FIDs 


If the FID field of the flow identification mobility option is not 
already present in the list of flow binding entries for this mobile 
node, then this is a request for a new entry. 


If the flow identification mobility option does not include a 
traffic selector sub-option, the home agent MUST reject this 
request by copying the flow identification mobility option in the 
Binding Acknowledgement (BA) and setting the Status field to the 
value defined in Figure 2 for "Flow identification option 
malformed". 


If the flow identification option does include a traffic selector 
sub-option, but the format indicated in the TS Format field is not 
supported, the home agent MUST reject this request by copying the 
flow identification mobility option in the BA, and setting the 
Status field to the value defined in Figure 2 for "Traffic 
Selector format not supported". 


Then, the home agent MUST check the binding reference sub-option. 


If the binding reference sub-option is not included, the home 
agent MUST reject this request by copying the flow identification 
mobility option in the BA and setting the Status field to the 
value defined for "Flow identification mobility option malformed" 
in Section 4.2. 


If the binding reference sub-option is present and includes one or 
more BIDs that are not present in the binding cache of the mobile 
node, the home agent MUST reject this request by copying the flow 
identification option in the BA and setting the Status field to 
the value defined for "BID not found" in Section 4.2. 


If the binding reference sub-option is present and includes one or 
more BIDs, and the BIDs exist in the mobile node’s binding cache, 
the home agent SHOULD add a new entry in the mobile node’s list of 
flow binding entries, as defined below. 


When the home agent decides to add an entry in the mobile node’s list 
of flow binding entries, as discussed above, it MUST do it according 
to the following rules: the entry MUST be placed according to the 
order indicated by the FID-PRI field of the flow identification 
mobility option and it MUST include: 
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the FID as a key to the entry, 

the traffic selector included in the corresponding sub-option, 

the BIDs indicated in the binding reference sub-option, and 

the entry MUST be marked as 'Active', as shown in Section 4.3. 
5.3.2.2. Handling Known FIDs 


If the FID field of the flow identification mobility option is 
already present in the list of flow binding entries for this mobile 
node, then this is a request to update the existing entry. 


The flow binding modification is essentially a process where 
parameters associated with an existing flow binding entry are 
replaced by the parameters included in a flow identification mobility 
option with the same FID as the existing entry. 


The home agent MUST change the priority of the entry according to the 
FID-PRI field of the flow identification mobility option. 


Since this flow identification mobility option is designed to update 
an existing entry, it may or may not include a traffic selector sub- 
option. Specifically: 


if a traffic selector sub-option is not included in the flow 
identification mobility option, then the traffic selector already 
associated with entry MUST be maintained; 


otherwise, the traffic selector in the entry MUST be replaced by 
the traffic selector in the sub-option. 


Since this flow identification mobility option is designed to update 
an existing entry, it may or may not include a binding reference sub- 
option. Specifically: 


if a binding reference sub-option is not included in the flow 
identification mobility option, then the BIDs already associated 


with entry MUST be maintained; 


otherwise, the BIDs in the entry MUST be replaced by the BIDs in 
the sub-option. 
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5.3.3. Handling Flow Summary Mobility Option 


When the home agent receives a binding update that includes flow 
summary mobility options, it first performs the operation described 
so far in Section 5.3. 


If the value of any of the FID fields included in a flow summary 
mobility option is not present in the list of flow binding entries 
for this mobile node, the home agent MUST reject this flow binding 
refresh by including a flow identification mobility option in the BA 
for each FID that is not found, and by setting the FID field to the 
value of the FID that is not found and the Status field to the value 
defined for "FID not found" in Section 4.2. 


If the value of the FID field is present in the mobile nodes list of 
flow binding entries the, home agent SHOULD refresh the flow binding 
entry identified by the FID without changing any of the other 
parameters associated with it. 


If a given FID is included more than once in the same or different 
flow summary mobility options in the same binding update message, the 
duplicates can be simply ignored. 


Note that, an [RFC3775] deregistration binding update (with a zero 
lifetime) would result in deleting all bindings, including all flow 
bindings regardless of the presence of flow summary mobility options. 
A binding update (with a zero lifetime) would result in deleting all 
bindings, including all flow bindings regardless of the presence of 
flow summary mobility options. A specific binding deregistration, 
however, as defined in [RFC5648] (with lifetime of zero and one or 
more binding identifier mobility options identifying specific BIDs) 
does not remove all the bindings for the MN, and thus it SHOULD 
include flow summary mobility options to maintain the flow bindings 
that need to be preserved. 


5.3.4. Flow Binding Removals 


Removal of flow bindings is performed implicitly by omission of a 
given FID from a binding update. 


When a valid binding update is received, any registered FIDs that are 
not explicitly referred to in a flow identification mobility option 
or in a flow summary mobility option, in the same binding update, 
MUST be removed from the list of flow binding entries for the mobile 
node. 
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3.5. Sending Binding Acknowledgements 


Upon the reception of a binding update, the home agent is required to 
send back a Binding Acknowledgement. The status code in the Binding 
Acknowledgement must be set as recommended in [RFC3775]. This status 
code does not give information on the success or failure of flow 
bindings. 


In order to inform the mobile node about the status of the flow 
binding(s) requested by a mobile node, flow identification options 
SHOULD be included in the Binding Acknowledgement message. 
Specifically, the home agent SHOULD copy each flow identification 
mobility option received in the binding update and set its status 
code to an appropriate value. Note that the home agent does not need 
to respond specifically regarding FIDs included in a flow summary 
mobility option but only to those in flow identification mobility 
options. If an operation requested in a flow identification option 
by a mobile node is performed successfully by the home agent, the 
Status field on the copied flow identification mobility option in the 
BA, SHOULD be set to the value defined for "Flow binding successful" 
in Section 4.2; otherwise, it SHOULD be set to one of the rejection 
codes also defined in Section 4.2. Section 5.3.2 identifies a number 
of cases where specific error codes should be used. 


Home agents that support this specification MAY refuse to maintain 
flow bindings by setting the Status field of any flow identification 
mobility options to the value defined for "Administratively 
prohibited" in Section 4.2, or by just ignoring all the flow binding 
options. 


Note that BID options and their Status field are handled as defined 
in [RFC5648]. The BID-PRI field in a BID option included in the 
Binding Acknowledgement is copied from the BID-PRI field of the 
corresponding BID option in the binding request. 


3.6. Packet Processing 


This section defines packet processing rules according to this 
Specification. This specification does not change any of the packet 
interception rules defined in [RFC3775] and [RFC5555]. These rules 
apply to HAs, MAPs, and CNs as part of the routing process for any 
packet with a destination address set to a valid home address of the 
mobile node. For nodes other than CNs, this also applies to packets 
with a destination address set to an address under any of the 
registered prefixes. These rules apply equally to IPv6 packets as 
well as to IPv4 packets as per [RFC5555]. 
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Before a packet is forwarded to the mobile node, it MUST be matched 
against the ordered list of flow bindings stored in the list of flow 
binding entries for this mobile node (see Section 4.3). A match is 
attempted with the traffic selector included in the first line 
(highest order) of the table. The first entry that creates a match 
defines how the packet is routed. When a packet matches the traffic 
selector of a given entry, a copy of the packet is forwarded to each 
of the care-of addresses associated with the BIDs indicated in the 
same line of the table. 


If any of the BIDs indicated does not correspond to a valid care-of 
address, e.g., the BID was deregistered then, that BID has no effect 
on the traffic. In other words, packets matching the flow binding 
are forwarded to the remaining BIDs, pointing to registered care-of 
addresses. If none of the BIDs pointed to in a flow binding entry is 
valid, then the entry is considered to be inactive (as defined in 
Section 4.3) and is skipped. In other words, packets should not be 
matched against that entry. 


If a packet does not match any of the active flow binding entries for 
the given MN, the packet SHOULD be forwarded to the highest order 
care-of address, i.e., the one associated with the BID with the 
lowest BID-PRI. 


If a packet is fragmented, only the first fragment contains all IP 
and transport layer headers, while subsequent fragments only contain 


an IP header without transport layer headers. For this reason, it is 
possible that subsequent fragments do not match the same traffic 
selector as the initial fragment of such a packet. Unless specific 


measures are taken, the likely outcome is that the initial fragment 
is routed as the MN intended while subsequent fragments are routed 
differently, and probably based on the default flow binding. HAs, 
MAPs, and CNs SHOULD take care to forward all fragments of a given 
packet the same way, and in accordance to the flow binding matching 
the first fragment of said packet. This should be possible given the 
fact that fragment headers include enough information to identify a 
fragment as part of a specific packet, but the details of how this is 
ensured are implementation specific and are not defined in this 
specification. 


6. MTU Considerations 


The options and sub-options defined in this specification add to 
those defined in [RFC3775] and other related specifications, all of 
which potentially add to the size of binding update messages. 
Implementations SHOULD take care to minimize fragmentation by forming 
binding updates that are shorter than what the path MTU allows 
whenever possible. 
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This specification offers a number of mechanisms for reducing the 
size of binding updates. The operations defined in this 
specification that require the most verbose options are those 
registering new BIDs, Section 4.1, and identifying new flows, 

Section 4.2.1.4. Implementations are encouraged to keep binding 
updates to sizes below that of the path’s MTU by making full use of 
the BID reference sub-option, Section 4.2.1.3, and flow summary 
option, Section 4.2.2, which allows them to refer to already 
registered care-of addresses and flow bindings, while registering new 
ones in subsequent binding update messages. 


7. Security considerations 


This document introduces a new option that adds more granularity to 
the binding update and acknowledgement messages defined in [RFC3775], 
[RFC5555], and [RFC3963], so it inherits the security considerations 
discussed in these documents. The new option allows the mobile node 
to associate some flows to one interface and other flows to another 
interface. Since the flow identification mobility option is part of 
the mobility header, it uses the same security as the binding update, 
whether it is sent to a mobility agent or to a correspondent node. 


This specification does not open up new fundamental lines of attack 
on communications between the MN and its correspondent nodes. 
However, it allows attacks of a finer granularity than those on the 
binding update. For instance, the attacker can divert or replicate 
flows of special interest to the attacker to an address of the 
attacker's choosing, if the attacker is able to impersonate the MN or 
modify a binding update sent by the MN. Hence, it becomes doubly 
critical that authentication and integrity services are applied to 
binding updates. 


Finally, when the optional anti-replay feature of Encapsulating 
Security Payload (ESP) [RFC4303] is employed and packets to/from 
different CoAs are sent on the same security association (SA), some 
packets could be discarded at the receiver due to the windowing 
mechanism used by this feature. Therefore, a sender SHOULD put 
traffic to/from different CoAs, but with the same HoA in the selector 
values, on different SAs to support Multiple Care-of Addresses 
appropriately. To permit this, the IPsec implementation SHOULD 
establish and maintain multiple SAs between a given sender and 
receiver, with the same selectors. Distribution of traffic among 
these parallel SAs to support Multiple Care-of Addresses is locally 
determined by the sender and is not negotiated by the Internet Key 
Exchange version 2 (IKEv2) protocol [RFC5996]. The receiver will 
process the packets from the different SAs without prejudice. 
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8. IANA Considerations 


This specification requires the following IANA assignments on 
existing namespaces as well as the creation of some new namespaces. 


New Mobility Options [RFC3775]: This registry is available from 
http://www.iana.org under "Mobile IPv6 parameters". The following 
type numbers have been assigned for: 
44 Flow Identification Mobility Option, defined in Section 4.2 
45 Flow Summary Mobility Option, defined in Section 4.2.2 
A new "Flow Identification Mobility Option Status Codes" namespace 
has been created. The following 'Status' codes are defined in 
this specification, in Section 4.2: 


O0 Flow binding successful 


1-127 Unassigned. Available for success codes to be allocated 
via Standards Action or IESG Approval as per [RFC5226]. 


128 Administratively prohibited 

129 Flow binding rejected, reason unspecified 

130 Flow identification mobility option malformed 
131 BID not found 

132 FID not found 

133 Traffic selector format not supported 


134-250 Unassigned. Available for reject codes to be allocated 
via Standards Action or IESG Approval as per [RFC5226]. 


251-255 Reserved for experimental use. This small number of 


status codes should be sufficient for experiments with 
currently unforeseen error conditions. 
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A new "Flow Identification Sub-Options" namespace for the flow 
identification mobility option has been created. The sub-option 
space is defined in Figure 3. The following sub-option Type 
values are defined in this specification: 


0 Pad 

1 PadN 

2 BID Reference 

3 Traffic Selector 


4-250 Unassigned. Available for allocation based on Standards 
Action or IESG Approval as per [RFC5226]. 


251-255 Reserved for experimental use. This small number of 
sub-option Types should be sufficient for experiments with 
additional parameters associated with a flow. 


A new "Traffic Selector Format" namespace for the traffic selector 
sub-option has been created. The traffic selector format space is 
defined by the TS Format field in Figure 5. The following values 
are defined in this specification: 


0 Reserved 


1-250 Unassigned. Available for allocation based on Standards 
Action or IESG Approval as per [RFC5226]. 


251-255 Reserved for experimental use. This small number of 
traffic selector format types should be sufficient for 
experiments with different ways of representing a traffic 
selector. 


Similar to the procedures specified for Mobile IPv6 [RFC3775] number 
spaces, future allocations from the new number spaces requires 
Standards Action or IESG Approval as per [RFC5226]. 
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